feat(swap): Soroban tokens in the swap picker (C3) - #3073

Spec §6: the trustline, its 0.5 XLM reserve and the reserve sheet are
classic-only. A non-held contract destination counted as needing a
trustline (two-op fee, reserve preflight, Max less 0.5 XLM). A held
contract source was offered as the reserve sheet's sell token, whose
receive quote is classic-only; it still has to cover the fee in XLM.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Spec §6 / C3: the picker keeps its sources (held tokens, stellar.expert
search and trending, asset lists) and stops filtering out Soroban
contract tokens.

- Held contract tokens appear in "Your tokens" (both pickers), with
  their balance at their decimals.
- Search and trending keep contract records, carrying stellar.expert's
  decimals onto the picked token, so the build knows them.
- Contract tokens are bulk-scanned with Blockaid as CODE-CONTRACT, as
  the Add token flow scans them.
- A contract token needs no trustline. isContract now means a Soroban-
  only token (contract issuer); a SAC is listed in its classic form.
- The "Soroban tokens aren't supported" empty state, hadSorobanMatches
  and the picker's now-unused isDestination prop are gone; e2e test 5
  now expects the contract token's row.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Spec §6 row subtitle: classic tokens keep the issuer's home domain; a
Soroban-only token shows its contract ID shortened (CBI7…IHRV), even if
it reports a domain, so a lookalike still looks different. Held rows
keep the balance subtitle they share with the account home.

The row menu's "View on stellar.expert" opens a contract token's
contract page; /asset/CODE-C… is not a stellar.expert page.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…hed on pick

Spec §6: icons come from the user's asset lists, then the issuer's
stellar.toml; the first hit is cached so the token looks the same
across the wallet. Discover rows showed stellar.expert's toml image even
when a list (or the wallet's icon cache) had another.

Rows now take the wallet's cached icon, else the first asset list's,
else the toml image stellar.expert returned with the record (its copy
of the issuer's stellar.toml, so no extra Horizon + toml round trip per
row). The picked token's icon is written to the Redux and background
icon caches, which the amount screen, review and account home read.
Rows are not cached at search time, so searches don't fill the cache
with tokens nobody picked.

findTokenListIcon is getIconFromTokenLists' lookup without its cache
write, so the picker can run it on every row.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Co-Authored-By: Claude Opus 5.5 <[email protected]>

User-approved decision: a contract token the account doesn't hold gets
its decimals from getDecimalsForAsset (the existing on-chain read via
/token-details), not from the stellar.expert row it was picked from and
never a silent 7. The read runs at the start of the build; if it fails,
the build stops before any quote or /swap/tx call, shows "Couldn't read
this token's details", and reports to Sentry.

getSwapTokenDecimals is gone; getHeldTokenDecimals only reads a held
balance, and getDecimalsForAsset is the one resolver. The sell input
still uses 7 for an unheld source, which has no balance to swap.

New tests: on-chain decimals reach /swap/tx's minOut; a 6 -> 18 decimal
build scales the amount sold and minOut to each side.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

swapQuote's contractIssuer (StrKey.isValidContract) and decodeSwapTx's
own StrKey check duplicated isContractId; both now use it.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

TX_SEND_MAX (922337203685.4775807) is the int64 stroop limit of a
classic amount; a contract token's i128 balance has no such cap, and at
18 decimals the cap is not even the right number. Send's validator has
the same cap and 7-decimal check for tokens; left alone here.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

User-approved decision: the picker shows icons through its lookup (the
wallet's icon cache, then asset lists, then the toml image) but never
writes the shared icon cache. Drops the pick-time write from 98dbc66;
the lookup and the shared icon pipeline are unchanged.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

User-approved decision: only mainnet has a source (LI.FI) that routes
contract tokens, so on testnet and other networks search and Popular
show no contract token the account doesn't hold. Held ones stay in Your
tokens. buildSwapSections now reads the networkDetails it was passed.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

User-approved decision: the asset details screen's Swap button now shows
for contract tokens too (not for liquidity-pool shares), opening Swap
with the token as the source, now that the swap flow handles them.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

A SAC added by contract ID without a trustline is held Soroban-shaped
(injectLocalTokenBalances), named after its classic asset. Picked as the
destination it counted as a contract token, so no reserve preflight and
no 0.5 XLM held back from Max before review.

Checked against freighter-backend-v2 #178 (lifi.go toClassic/BuildTx):
the backend detects a SAC destination from its contract instance and
lets LI.FI's trust(account) through; decodeSwapTx reads it as
addsTrustline, so the build and the review's trustline banner already
worked. Only the pre-review reserve check was missing.

An unheld SAC returned by stellar.expert as a bare contract record would
still be missed; stellar.expert returns SACs in classic form.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

"Swap for 0.5 XLM" swaps the best classic balance into XLM, but left
isToken as a Soroban source had set it, so the review showed empty
Soroban fee rows and asked RPC whether the classic source's SAC supports
muxed addresses. Both sides are classic after it.

The direction toggle also writes isToken false when the new source is a
held Soroban token; the swap review reads Soroban fees from the build's
resource fee, so that one shows nothing wrong and is left as is.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

stellar.expert can return a SEP-41 contract with no code metadata; the
picker showed it as a blank row and carried an empty code to the amount
card and review. Its code falls back to the shortened contract ID, as
its subtitle already shows. The Add token flow's mapStellarExpertRecord
has the same empty fallback; outside swap, left as is.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

# Conflicts:
#	extension/src/popup/components/swap/SwapAmount/index.tsx

# Conflicts:
#	extension/src/popup/components/swap/SwapAmount/__tests__/SwapAmount.liveQuote.test.tsx
#	extension/src/popup/components/swap/SwapAmount/hooks/__tests__/useSimulateSwapData.test.ts
#	extension/src/popup/components/swap/SwapAmount/hooks/useSimulateSwapData.tsx
#	extension/src/popup/helpers/swapQuote.ts

The picker sent every search term to stellar.expert, so a contract
token it does not index, or any term during a stellar.expert outage,
came back "No tokens match" and could not be picked, though quoting and
building would handle it. Mobile reads a pasted contract ID through
token-details (handleContractLookup); the extension now does the same
(Piyal's call, 2026-11-11), reusing the Add-token lookup's pieces: the
backend's token details, isSacContractExecutable for a SAC, which is
listed as its classic asset so the trustline logic applies, and the
native row for XLM's own contract.

getTokenDetails gains throwOnFailure, as mobile's did, so a failed read
can be told apart from "not a token": a 400 is an answer (null), any
other failure throws into the lookup's existing catch, which serves the
cached result or the held-only fallback with its "discovery unavailable"
notice, the same path a failed stellar.expert search takes. Other
callers keep the old swallow-and-null behaviour.

Found by /code-review and the drift review on #3073.

Co-Authored-By: Claude Fable 5.1 <[email protected]>

The toggle cleared isToken unconditionally. With C3 a held contract
token can sit on either side, and the review reads isToken against
srcAsset (getContractIdFromTransactionData) for its contract memo and
muxed-address checks, so toggling a held contract token into the sell
slot left the review treating it as classic. isToken now follows the
token that lands in the sell slot; an empty slot (a non-held
destination that could not move) reads as classic.

Every saveIsToken in the swap flow, and which side it derives from:
- SwapAmount reserve prefill: false; the new source is a classic
  non-XLM token (correct).
- SwapAmount direction toggle: now the new source (this commit).
- Swap view source pick: the picked source's isContract (correct).
- Swap view destination pick: the picked DESTINATION's isContract,
  which is the other side from what the review reads; left as is here.
- Swap view deep-link source: false only when the source param is XLM;
  a classic or contract source param leaves the previous value; left
  as is here.

Copilot thread on #3073.

Co-Authored-By: Claude Fable 5.1 <[email protected]>

handleDestinationPick decided "held" from the Your tokens rows, which in
search mode are only the rows the term matched. A held SYM:C1 found
through its ABC:C1 search row (listed as held since 44e8fee) then got
a pick-time decimals read and was stored as ABC:C1. The pick now looks
the row's contract up against every held balance, the set Popular
filters against, and a held match is picked as the balance: its
canonical, symbol and decimals, no read. Mobile's picker takes the same
rule.

Medium review on the C3 fix round.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

isToken describes the source: the review reads it against srcAsset for
its contract memo and muxed-address checks (see 0912ca0). The
destination pick set it from the destination, so a contract source with
a classic destination picked was reviewed as classic, and a contract
destination flipped it on for a classic source. The pick no longer
writes it; when it clears the source (same-token reset) it clears
isToken with it.

Medium review on the C3 fix round.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

getTokenDetails parsed the body before checking for the 400 that means
"not a token", so the backend's plain-text 400 ("Soroban has been
disabled on pubnet") threw a SyntaxError, which throwOnFailure turns
into a failed lookup. The status is now checked first, matching
mobile's axios path, which never parses a 400's body.

Medium review on the C3 fix round.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

The read took the public key from the picker's account data, which can
still be loading when Popular rows are already on screen; a tap then
sent an empty key and the backend answered 400. It now reads the active
account's key from Redux (publicKeySelector), as the rest of the swap
flow does.

Medium review on the C3 fix round.

Co-Authored-By: Claude Opus 5.5 <[email protected]>